wafer.space Community - 💻-digital

Hi! If we have some 1024x64 or 1024x32 SRAM Macro? (edited)

Zhekar1998

Hi! If we have some 1024x64 or 1024x32 SRAM Macro? (edited)

You can find the foundry provided SRAMs here: https://github.com/wafer-space/gf180mcu/tree/main/gf180mcuD/libs.ref/gf180mcu_fd_ip_sram/gds They are 8 bits wide, so you'll need to use several in parallel. There are also community-designed 3.3V SRAMs, but they haven't been verified yet.

Okay, I finally have a reproducible for the whole LVS gets stuck with my SCL issue Clone the SCL repo at https://github.com/AvalonSemiconductors/gf180mcu_as_sc_mcu7t3v3 Open a terminal in example_project nix-shell make clone-pdk make setup make

11:06 p.m.

You can disable DRC to make it go faster

@Tholin : Here is a complete set of xschem symbols for your GF 3.3V standard cell library, if you could please add it under libs.tech/xschem.

xschem.tgz

6.83 KB

Certainly. Good work.

Hi everyone. This is my first public open-silicon review package, so I’d really appreciate ASIC/PD feedback. I built a compact 3.3V-only GF180 I/O candidate library for wafer.space/open MPW experiments:

160um pad depth
100 signal pads
~17.3mm² usable core area
local DRC/LVS completed
LEF/CDL/SPICE/Liberty/IBIS generation
preliminary ngspice PVT/DC characterization
config/package generation flow included

The project was developed using an automated agent-in-the-loop exploration flow with manual review and verification. Main goal: reduce padframe overhead for small GF180 SoCs. Any comments on architecture, verification flow, pad strategy, or obvious mistakes would be greatly appreciated. https://github.com/Detronyx-labs/gf180_compact_3v3_io.git

GitHub - Detronyx-labs/gf180_compact_3v3_io: Compact open GF180MCU ...

Compact open GF180MCU 3.3V-only I/O pad library candidate for wafer.space MPW: transistor-level pad cells, LEF/CDL/SPICE/Liberty/IBIS views, compact 160um padframe, I3C-capable bidirectional pads, ...

1

1

@Tim Edwards Hi Tim, I finally cleaned up and published my GF180MCU 3.3V 12T 2R2W SRAM macro experiment, which borrows from the transistor/layout concepts in your 512x8 reference. Repo (Apache-2.0): https://github.com/Detronyx-labs/gf180mcu-3v3-12t-2r2w-sram-macro To be completely honest, this is a fast AI-native / agentic design experiment — put together in about 3–4 days of intense work alongside Codex/LLM to see how far an automated open flow could push a custom multi-port layout. It is definitely not tapeout signoff collateral yet. If you (or anyone here) have a few minutes to glance at the README, I’d love to get a brutal reality check from actual silicon experts on a few things: Physical & Escape Routing: Are the 12T bitcell layout and shared M4/M5 escape assumptions physically defensible for GF180, or are we begging for major EM/IR-drop failures during simultaneous 2R/2W operations? Extraction limitations: My local Magic techfile isn't emitting capacitance coefficients for this flavor, so we’re stuck using an OpenRCX geometry-fallback proxy for timing (which throws warnings). How critical is it to escape open-source PEX fallbacks for a custom multiport memory structure like this? Prioritization: We have open items for full-macro LVS on row-edge boundaries, Liberty generation, and SNM/read-disturb sweeps. What should we absolute priority-target next to move this closer to tapeout-intent collateral? Your documentation was a lifesaver for understanding practical GF180 implementation, so any feedback on where this automated flow breaks down in the real world would be awesome. Thanks!

GitHub - Detronyx-labs/gf180mcu-3v3-12t-2r2w-sram-macro: Open 12T 2...

Open 12T 2R2W SRAM hard macro for GF180MCU 3.3V. Contribute to Detronyx-labs/gf180mcu-3v3-12t-2r2w-sram-macro development by creating an account on GitHub.

1

Zhekar1998

@Tim Edwards Hi Tim, I finally cleaned up and published my GF180MCU 3.3V 12T 2R2W SRAM macro experiment, which borrows from the transistor/layout concepts in your 512x8 reference. Repo (Apache-2.0): https://github.com/Detronyx-labs/gf180mcu-3v3-12t-2r2w-sram-macro To be completely honest, this is a fast AI-native / agentic design experiment — put together in about 3–4 days of intense work alongside Codex/LLM to see how far an automated open flow could push a custom multi-port layout. It is definitely not tapeout signoff collateral yet. If you (or anyone here) have a few minutes to glance at the README, I’d love to get a brutal reality check from actual silicon experts on a few things: Physical & Escape Routing: Are the 12T bitcell layout and shared M4/M5 escape assumptions physically defensible for GF180, or are we begging for major EM/IR-drop failures during simultaneous 2R/2W operations? Extraction limitations: My local Magic techfile isn't emitting capacitance coefficients for this flavor, so we’re stuck using an OpenRCX geometry-fallback proxy for timing (which throws warnings). How critical is it to escape open-source PEX fallbacks for a custom multiport memory structure like this? Prioritization: We have open items for full-macro LVS on row-edge boundaries, Liberty generation, and SNM/read-disturb sweeps. What should we absolute priority-target next to move this closer to tapeout-intent collateral? Your documentation was a lifesaver for understanding practical GF180 implementation, so any feedback on where this automated flow breaks down in the real world would be awesome. Thanks!

I've been working with Tim to get full-die PEX into a state that's reasonably considered "functional" for smoke testing with Xyce; a major block to using it for fancier behavioral testing is the need to use a separate digital logic simulator (verilator or so? not sure what exactly tbh.) to find FF/latch states of the entire chip at the desired jump-off point for a transient test run, and associating those to the individual signals in the chip to synthesize .nodeset commands that force the chip into that desired starting state with an initial DC-operating-point solution, from where it'd then continue settling a DC solution from that moment on that doesn't have the signals pegged to hard VDD/VSS anymore, followed by a few clocks of progress to let at least a bit of PDN parasitics settle in, before then doing the actual state changes of desired concern. The extraction into Xyce-compatible PEX with a lot of parasitic resistance and capacitance modeled is already working though; there's just a bit of scaling performance that seems to be left. If you want I can test extraction on that macro later. I need for that to work only top-level pins to be labeled; the rest will be flattened in KLayout if it's not already flattened, before I feed it to the PEX.

@Zhekar1998 Also if you're willing I'd love to talk a bit about how us two have been doing agentic "PCell" construction:

you with the 12t-2r2w gf180mcuD sram, using Codex,
I with so far a base MCML VCO cell but soon also the other base SerDes component cells (XOR2, MUX2, D-latch at least) on sky130A but with a bit of luck I can port that to gf180mcuD (in time to get a base demo VCO clocking an output MUX that's fed with a 16-wide PBRS-31 generator) into Run2), using Jules.

Zhekar1998

@Tim Edwards Hi Tim, I finally cleaned up and published my GF180MCU 3.3V 12T 2R2W SRAM macro experiment, which borrows from the transistor/layout concepts in your 512x8 reference. Repo (Apache-2.0): https://github.com/Detronyx-labs/gf180mcu-3v3-12t-2r2w-sram-macro To be completely honest, this is a fast AI-native / agentic design experiment — put together in about 3–4 days of intense work alongside Codex/LLM to see how far an automated open flow could push a custom multi-port layout. It is definitely not tapeout signoff collateral yet. If you (or anyone here) have a few minutes to glance at the README, I’d love to get a brutal reality check from actual silicon experts on a few things: Physical & Escape Routing: Are the 12T bitcell layout and shared M4/M5 escape assumptions physically defensible for GF180, or are we begging for major EM/IR-drop failures during simultaneous 2R/2W operations? Extraction limitations: My local Magic techfile isn't emitting capacitance coefficients for this flavor, so we’re stuck using an OpenRCX geometry-fallback proxy for timing (which throws warnings). How critical is it to escape open-source PEX fallbacks for a custom multiport memory structure like this? Prioritization: We have open items for full-macro LVS on row-edge boundaries, Liberty generation, and SNM/read-disturb sweeps. What should we absolute priority-target next to move this closer to tapeout-intent collateral? Your documentation was a lifesaver for understanding practical GF180 implementation, so any feedback on where this automated flow breaks down in the real world would be awesome. Thanks!

The gds from gf180mcu_3v3_12t_2r2w_sram_512x8 seems to short the VSS PDN columns of the top level cell due to misalignment across the VSS colunn and c3_r1_rbl of the 4x4 block. Please get at least basic LVS verification going before suggesting humans other than you yourself should look at the layout and give their opinions. Exceptions would apply if without having to open a zipfile I could easily see that you're disclaiming that level of integration LVS to have been done.

namibj

The gds from gf180mcu_3v3_12t_2r2w_sram_512x8 seems to short the VSS PDN columns of the top level cell due to misalignment across the VSS colunn and c3_r1_rbl of the 4x4 block. Please get at least basic LVS verification going before suggesting humans other than you yourself should look at the layout and give their opinions. Exceptions would apply if without having to open a zipfile I could easily see that you're disclaiming that level of integration LVS to have been done.

Thanks! Its interesting because I do LVS all times in every runs, I recheck it now

3:47 a.m.

Yes I find it. sorry I do some mistake in rules

3:48 a.m.

I'll repear it and double check it by hands today)))

I don't know how you do that LVS but I suggest you attempt to do it on a flattened layout to check the hierarchy isn't causing problems. It's hard to pin-point problems that way, but I'm pretty sure a basic abstracted-transistors (N/P and 3/4 pins) should be very much practical and a reliable check via graph-matching should be not-a-problem.

Zhekar1998

I'll repear it and double check it by hands today)))

I have no idea what timezone you're sleep/wake cycle corresponds to; I am as mentioned interested in talking to you (German or English, your choice) about the flow and struggles of this agentic-scripted-cells flow. Just in case you may be interested, that is.

namibj

I have no idea what timezone you're sleep/wake cycle corresponds to; I am as mentioned interested in talking to you (German or English, your choice) about the flow and struggles of this agentic-scripted-cells flow. Just in case you may be interested, that is.

I'm in GMT +2 but. I will be hapy to speak about this

Zhekar1998

I'm in GMT +2 but. I will be hapy to speak about this

oh same great then. I've got a bit of stuff to do offline but in like 2 hours I'd have time to talk. Sent you a DM for further discussing of that.

1

namibj

The gds from gf180mcu_3v3_12t_2r2w_sram_512x8 seems to short the VSS PDN columns of the top level cell due to misalignment across the VSS colunn and c3_r1_rbl of the 4x4 block. Please get at least basic LVS verification going before suggesting humans other than you yourself should look at the layout and give their opinions. Exceptions would apply if without having to open a zipfile I could easily see that you're disclaiming that level of integration LVS to have been done.

I fix it now. Its was mistake with logic of generator script.

Zhekar1998

@Tim Edwards Hi Tim, I finally cleaned up and published my GF180MCU 3.3V 12T 2R2W SRAM macro experiment, which borrows from the transistor/layout concepts in your 512x8 reference. Repo (Apache-2.0): https://github.com/Detronyx-labs/gf180mcu-3v3-12t-2r2w-sram-macro To be completely honest, this is a fast AI-native / agentic design experiment — put together in about 3–4 days of intense work alongside Codex/LLM to see how far an automated open flow could push a custom multi-port layout. It is definitely not tapeout signoff collateral yet. If you (or anyone here) have a few minutes to glance at the README, I’d love to get a brutal reality check from actual silicon experts on a few things: Physical & Escape Routing: Are the 12T bitcell layout and shared M4/M5 escape assumptions physically defensible for GF180, or are we begging for major EM/IR-drop failures during simultaneous 2R/2W operations? Extraction limitations: My local Magic techfile isn't emitting capacitance coefficients for this flavor, so we’re stuck using an OpenRCX geometry-fallback proxy for timing (which throws warnings). How critical is it to escape open-source PEX fallbacks for a custom multiport memory structure like this? Prioritization: We have open items for full-macro LVS on row-edge boundaries, Liberty generation, and SNM/read-disturb sweeps. What should we absolute priority-target next to move this closer to tapeout-intent collateral? Your documentation was a lifesaver for understanding practical GF180 implementation, so any feedback on where this automated flow breaks down in the real world would be awesome. Thanks!

@Greg - You where interested in this?

It's ... LLM generated garbage ...

tnt

It's ... LLM generated garbage ...

I'll see to it; though this weekend including Monday+Tuesday (recovery) I'll be running on fumes, trade fair intense and weather melting.

It'd be faster to start from scratch

tnt

It'd be faster to start from scratch

I meant I'm gonna talk to them about their methodology in the general endeavor "vibe coding PCell/macro-generator". I don't like it when people drop broken slop at one's feet and request through whatever phrasing/request that one should code-review the broken slop.

1

tnt

It's ... LLM generated garbage ...

To give you the full picture: OpenRAM isn't available for GF180MCU at all, so I had to find a workaround for my project. I didn't just raw-prompt an LLM — I actually ran it in a verification loop with KLayout, Magic, and Netgen-LVS until it passed for my two specific configurations. That said, I'm still just learning VLSI fundamentals, and I totally understand that an LLM-in-the-loop hack doesn't replace a proper, scalable macro-generator methodology. I’d love to join the discussion on how to build a robust generator the right way from scratch. I fully understand about this project can have mistakes but, without mistakes its imposible to learn.

3:31 p.m.

I try to build pipline where LLM will be generate code from big blocks and transistors. but not allways I can find generation mistaces

Staf will port his flexmem SRAM generator to gf180mcu for ws-run #2.

Chips4Makers / c4m-flexmem · GitLab

A flexible, scalable memory generator.

Leo Moser (mole99)

Staf will port his flexmem SRAM generator to gf180mcu for ws-run #2.

Oh thanks, I'll check it, Its can be helpfull

RebelMike started a thread. 2026-05-28 7:36 a.m.